1. Field of the Invention
The present invention relates to industrial automation systems and, more particularly, to a web server component and method for providing access to device configuration data within an industrial automation system.
2. Description of the Related Art
Industrial automation systems are used to monitor, control and regulate technical processes, particularly in the field of production, process and building automation, and to enable an operation of control units, sensors, machinery and industrial plants that is intended to be performed as autonomously and as independently from human intervention as possible. Due to a constantly increasing importance of information technology for automation systems comprising numerous networked control and computer units, methods for the reliable provision of functions distributed over an automation system are becoming increasingly important for a provision of monitoring, control and regulating functions.
Interruptions of communication connections between computer units of an industrial automation system or automation devices can result in an unwanted or unnecessary repetition of the transfer of a service request. This causes an additional utilization of communication connections of the industrial automation system, which may result in further system failures or faults. Furthermore, messages that have not been transmitted or have not been completely transmitted may, for example, prevent an industrial automation system from switching to or remaining in a safe operating condition. This may ultimately result in an outage of a complete production plant and a costly production stoppage. Within industrial automation systems, one particular problem is regularly caused by message traffic with comparatively numerous but relatively short messages, as a result of which the above problems are exacerbated.
EP 1 770 458 A2 describes an industrial automation system with at least one programmable logic controller module in which a configuration unit is provided for configuring the control unit and for announcing its availability on a communication network. The configuration unit allocates a unique communication network address which may, for example, be an IPv6 address to the control unit. In this way, the control unit can be automatically placed into service.
U.S. Pat. No. 7,333,510 B1 discloses a data transfer method in which a name service component records IPv4 addresses and allocated device names within a subnetwork for a group of communication devices. An IPv6 address is calculated in each case for the group of communication devices from an Ipv6 prefix allocated to the subnetwork and the Ipv4 addresses of the communication devices. Furthermore, address conversion rules are determined for the group of communication devices from the Ipv4 addresses of the communication devices and the calculated IPv6 addresses. The determined address conversion rules are applied by an address conversion unit for an address conversion between IPv4 addresses and IPv6 addresses.
A conversion of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) communication connections that are based on Internet Protocol, Version 6 (IPv6), to communication connections based on Internet Protocol, Version 4 (IPv4), is described in Internet Engineering Task Force (IETF), Request for Comments (RFC) 6145 and 6146, ISSN 2070-1721, April 2011. A conversion of this type is referred to as Network Address Translation (NAT64). IPv6-based communication devices can access IPv4-based communication devices via NAT through the performance of an address format adaptation. In NAT64, in order to access IPv4 communication devices, IPv6 communication devices use virtual IPv6 addresses that are replaced by a NAT64 server with Ipv4 addresses allocated to the IPv4 communication devices. Similarly, communication network addresses for back channels are converted from IPv4 communication devices to IPv6 communication devices. In principle, an allocated forward channel must first be configured for a back channel.
It is additionally known from IETF, RFC 6147 to calculate allocated IPv6 address entries (AAAA Resource Records) in a Domain Name System (DNS) from IPv4 address entries, which are referred to as A Resource Records (RR), and to make these IPv6 address entries available via DNS servers. In principle, a derivation of AAAA Resource Records from A Records can be achieved manually by a DNS administrator, can be planned via an IP Address Management (IPAM) solution or can be determined continuously and automatically via DNS64 servers. An automatic determination via DNS64 servers is appropriate whenever an AAAA Resource Record is requested for a name for which only A Resource Records exist.
Many automation devices now comprise integrated Web servers. Users can display diagnostic or device configuration information in a simple manner via integrated web servers of this type. This also includes diagnostic device configuration information of subordinate automation devices or field devices that can be retrieved via links in overview pages of a superordinate automation device. If the subordinate automation devices or field devices in particular have IPv4 addresses only, a correct resolution of the links in the overview pages is problematic in the case of access from an IPv6 subnetwork. Problems of this type cannot be solved through the use of interposed NAT64 routers alone if address details are embedded in data at application protocol level (Layer 7 according to the OSI communication model). Address details of this type cannot be recorded by NAT64 routers, because these routers operate at network or transport protocol level (Layers 3 and 4 according to the OSI communication model).